1. Field of the Invention
This invention relates generally to wireless and long distance carriers, Internet Service Providers (ISPs), and information content delivery services/providers and long distance carriers. More particularly, it relates to location services for the wireless industry.
2. Background of Related Art
Location information regarding subscribers is becoming increasingly available in a wireless network. Location information relates to absolute coordinates of a wireless device.
FIG. 7 shows a conventional LoCation Services (LCS) request.
In particular, as shown in FIG. 7, a location server 106 requests location information regarding a particular mobile subscriber (MS) from a core network node, e.g., from a Mobile Switch Center (MSC) 110. Requested information regarding a particular wireless device (MS) may include, e.g., attach, detach, and location area update. The location server 106 may also request information regarding the wireless device such as attach, detach and/or location area update from a Packet Data Node (e.g., SGSN, GGSN, or PDSN), or help the device calculate x/y direction. Typically, location information regarding a particular wireless device is requested of a home location register (HLR).
As shown in step 1 of FIG. 7, a locations services client 104 sends a message to a location server 106.
In step 2, the location server 106 sends a Provide Subscriber Info message to a Home Location Register 108, requesting subscriber information regarding a particular subscriber.
In step 3, the carrier's Home Location Register (HLR) 108 provides the subscriber information for the requested subscriber back to the location server 106.
In step 4, location information regarding the requested subscriber is requested to either an MSC or Packet Data node 110. The MSC or Packet Data Node preferably provides precise location information using, e.g., a global positioning satellite (GPS), triangulation techniques, or other relevant locating technology, or helps the device calculate X/Y direction.
In step 5, the location request is forwarded to the Radio Access Network (RAN) 112 if needed.
In step 6, precise, updated location information regarding the requested subscriber is sent to the location server (LS) 106.
In step 7, an ultimate response to the original location request is sent to the LCS client 104 that initially requested the location information.
Secure User Plane for Location (SUPL) is a standards-based protocol that has been developed to allow a mobile handset client to communicate with a location server, e.g., as shown in step 1 of FIG. 7. The SUPL specification is defined by the Open Mobile Alliance (OMA) standards working group. Refer to OMA Secure User Plane Location Architecture document, OMA-AD-SUPL-V1—0-20060127-C for more details on OMA SUPL call flows; and OMA User Plane Location Protocol document, OMA-TS-ULP-V1—0-20060127-C. The OMA SUPL Version 1 specifies two basic types call flows: (1) a SUPL network initiated (NI) call flow, and (2) a SUPL set initiated (SI) call flow. According to the SUPL standard, a session ID has a unique value consisting of server and handset portions.
The conventional Presence Information Data Format-Location Object (.PIDF-LO) was developed by the GEOPRIV working group, and is the Internet Engineering Task Force (IETF) recommended way to encode location information. Location information in PIDF-LO format may be implemented in a variety of ways, including in presence based systems, and in the context of emergency services and other location based routing applications.
The PIDF-LO format provides for an unbounded number of tuples. (A “tuple” generally relates to a group of anonymous data values traveling together. The word is a generalization of the sequence: couple, triple, quadruple, quintuple, sextuple, etc.)
The geopriv element resides inside the status component of a tuple, hence a single PIDF document may contain an arbitrary number of location objects, some or all of which may be contradictory or complementary. The actual location information is contained inside a <location-info> element, and there may be one or more actual locations described inside the <location-info> element.
Generally speaking, the structure of a PIDF-LO can be depicted as follows:
PIDF-LO document    entity (person)    tuple 1       status          geopriv              location-info          civicAddress              location    tuple 2    tuple 3
The conventional PIDF-LO format provides information relating to location, time and status to individuals and entities. The PIDF-LO structure is intended for use with standardized Internet protocols, including Internet protocol (IP), Session Initiation Protocol (SIP), and Simple Object Access Protocol (SOAP).
For multi-media communications using Session Initiation Protocol (SIP), the location of a caller can be indicated in PIDF-LO format. SIP is an Internet Engineering Task Force (IETF) standard protocol for initiating an interactive user session that involves multimedia elements such as video, voice, chat, gaming, virtual reality, etc. SIP is specified in IETF Request for Comments (RFC) 3261 (replacing 2543). Like HTTP or SMTP, SIP works in the application layer of the open systems interconnection (OSI) communications model. SIP can also be used to invite participants to sessions that do not necessarily involve the initiator. Because SIP supports name mapping and redirection services, it makes it possible for users to initiate and receive communications and services from any location, and for networks to identify the users wherever they are. SIP is a request-response protocol dealing with requests from clients and responses from servers. Participants are identified by SIP universal resource locators (URLs). Requests can be sent through any transport protocol, such as UDP, SCTP, or TCP. SIP determines the end system to be used for the session, the communication media and media partners, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination.
FIG. 8 shows a conventional Presence Information Data Format-Location Object (PDIF-LO) format document, as defined by the Internet Engineering Task Force (IETF).
In particular, FIG. 8 shows an example of civic and geospatial location information use in conventional PIDF-LO format document. In the given example, an entity named Mike is visiting his Seattle office and connects his laptop into an Ethernet port in a spare cube. In this case the location is a geodetic location, with the altitude represented as a building floor number. The main location of user is inside the rectangle bounded by the geodetic coordinates specified. Further that the user is on the second floor of the building located at these coordinates.
Of particular note in FIG. 8 is that the entity list is conventionally used to identify a physical entity:                entity=“pres:mike@seattle.example.com”Generally speaking, conventional PIDF-LO presence lists are used to identify a person. An example person entity=Don@telecomsys.com and a corresponding example name= is “Don Mitchell”.        